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Summary This section describes the processing of priority levels, 

including context saving of interrupted tasks and the assignment 
Df priority levels and logical resource numbers to tasks. This 
section also describes task communication and coordination as 
well as deferred processing. 
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INTRODUCTION 

A task can De characterized as the execution of a sequence of 
instructions that has a starting point and an ending point, and 
perforins some identifiable function, A task can Initiate 
another task for execution or terminate itself by calling the 
task iTfdnagement ccnmands or macrocal ] s. Multiple tasks can 
operate inflependently of and asynchronousli' to each other. 

Each application, systeir, or device driver task operates at an 
interruDi priority level, one of the 64 oriority levels provided 
for each central processor b> the hardware and firrfiware, 

CENTRAL PROCESSOR INTERRUPT PRIORITY LEVELS 

All syater^ tasks, device drivers, and application tasks are 
assigned interrupt priority levels that indicate the order of 
their execution. This order of execution may be changed due to 
timeslking {see below) or because this I5 a multiprocessor 
system - 

Control of the central processor is given tc the highest active 
interrupt level. However, in multiprocessor systems, a task at 
a lov^er priorit^y may execute at the same time as a task of 
higher priority since each task is executing on a different 
centra] processor. 

Number of Each central processor provides 54 potential interrupt priority 

Levels levels that are used by the hardware to order the processing of 

evpnts. These levels are numbered from the highest priority 
(lewel 0) to the lowest priority (level 63). Levels through 
5, 62» and 63 are reserved. The intervening levels (6 through 
61) are assigned to logical resouTces (Chat Is. dewices and 
tasks). 

Activity The deteminet^on of which priority level is to receive central 

indicators processor time Is based on a linear scan of the level activity 

indicators. The level activity' indicators are rnaintained by the 
hardware in four contiguous dedicated memory locations In each 
central processor (see Figure 5-1). Each bit that is *'on" 
denotes an active priority level; each bit that is "cff" denotes 
an inactive level , 

interrupts Bits can be set "en" by software or by hardware events 

(interrupts). Most Interrupting hardware devices are associated 
with priority levels during system configuration (by directives 
in the CLMUSER file). 
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Figure 5-1. Ftjnnat of Level Activitj" Indicators for Each 
Central Processor 



Available The three highest priority levels Uaw^ dedicated assignments of 

Levels soedal hdrdware/firmware functions such as incipient power 

failure, watchdog timer runout, and trao save area overflow* 
Prioriti' level 3 1e reserved as an ■nhioit level, level 4 is 
reserved for the timeslice clock, and level 5 is dedicated to 
the real-time cIock, Succeeding levels are user-configurable as 
device levels. Following these are five levels reserved for 
system use. Except for levels 62 and 63, the remaining levels 
can &E usefl for application tasks. Level 62 is reserved for 
system use. Level 63 1S reserved for an always active software 
idle loop or, in multiprocessor systems, for the task 
dispatcher. 

Interrupt When & given priority level Is the highest active level, it 

Processing receli-es all avallaOe central processor time until lt is 

interrupted by a higher oriority level or until it relinquishes 
control by suspending itself (setting its level activity 
indicator off). If a priority level is interrupted by a higher 
priority level, its level acti^^iry Indicator remains on and it 
will resume execution of the interrupted logical resource when 
it again becomes the highest priority level. 

Each time a priority level change occurs, the hardware/firmware 
saves the central processor context of the task running at the 
previously highest active level and restores the central 
processor conte>!t of the task rur>nlng at the new highest active 
level. Interrupting a task, saving the context of a task, 
selecting anc3 starting the highest priority level task, and 
restoring the context of a task are aone without software 
InvQl vement. 
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INTERmjPT SAVE AREA 

Tdsl; Context The context of a level (task) can include the contents of the 
prograrr counter, S-reglster, B-reglEter5, I-regiiter, 
K-reg1sters, R-registers, M-registers, 51P registers, and CIP 
registers. The context is stored for each central processor in 
a block cf memory known as an Interrupt Save Area (ISA). 



Interrupt 
Vectors 



The herdware/firmware context save/restore function finds the 
appropriate ISA through a pointer supplied Sn the interrupt 
vector for that level. The interrupt vectors are a set of 
contiguous memory locations containing an entry for each 
potentially active priority level and ordered by ascending 
priority level number. Figure 5-2 Illustrates the order of the 
priority levels, their corresponding interrupt vectors, and the 
format of an ISA. 
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TASK DISPATCHING 



The way in which a task receives central processor time depends 
on whether the system has one or more than one central 
prDcessor, 

In a monoprocEssor system, tasks are dispatched according to 
their priority leveT, The task at the highest pnority level 
receives all available centra' processor time until it is 
interrupted by a tasK with a tngher priority leve' or until ^t 
suspends itself- Jn a multiprocessor syst^n, all tasks are 
dispatched fr^m a general ready queue. The taslcs are placed in 
the queue according tc their pr'^ority level, with higher 
priority tasks at the too of the queue. The level at which a 
tast executes stays the sarre, but the central processor in which 
it executes may vary. 



Monoprocessor Task Dispatching 



^hen a task ln a monoprocessor system is at the hiqnest active 
P'-ioriti' level, it receives aM ava^lat>le central processor time 
until it is interruptefl by a task at a higher priority level, 
until it relinouTshes control by suspending itself, or until it 
has control taken away frorn it due to timeslicing (see selow). 
If a task is interruptea h}/ a higher priority task, it will 
resume execution when it again becomes the task at the highest 
priority 'evel . 

When more than one task is assigned the same priority level , a 
system software task at a 'iigher level regulates in round-robin 
fashion the shar-^ng [}f the level between tasks. Thu^ a task 
does not block a level when the task is timesliced [refer to 
"T^mesliCTng" below) or when It is put in a waiting state after 
a request to wait, wait en list, request sen^aphore, or 
terminate, or after a system service macrocall that waits for a 
data transfer, instead, the contejct of another task on the same 
level win be linkeC to the level interrupt vector. 



Muftiprocessor Task Dispatching 



In a mul tip''0ces5Dr system, the Executive maintains a queue of 
read> tasks ordered by priority level. This queue is called the 
general ready i^ueue. The Executive aispatcnes the task at the 
top of the queue whenever a central processor becomes free to 
provide service, A disoatcher task rjns at level 63 in each 
central processor and dispatches a task whenever it receives 
central processor time- The dispatcher ta5h;s attempt to balance 
the load so that high prioriti^ tasks art serviced before low 
priority tasks, and all orocessors dr^ used as fully as 
possible. 
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TIMESLICING 



The technique of timeslicmc fmnimizes the ability of use-" 
tasks, that use large mcuuls of central prccessor time, to 
interfere with interactive -sers cf the system. Tirres^ldng 
^jses a samDimg technique to monltcr all iask5 at user leveU- 
Conf'Tguration of tlneslic-nc is automatic. All usen levels 
execute ^n a tifpeslnced man.-^er. Timeslicing options are 
ciscussed in the Systera Bui'tdlng ana Adntln^^tration manual. 



Each running user task is mcnitored b>' the scftware timeslicer 
logic. Eacn user task is given a CPLf time allocation (a time 
slice), the amount of which has been determined by system 
software and is governed by tne arguments (default or exp 
associatec with the OSLICE tound unit. 



icit 



While a user task tb runmng, timesliclng software is counting 
down ihe task's tine silce allocation. 

When a tasK'E tifne slice allocation becomes exhausted, the 
timeslice software, in general, will dequeue the sliced task and 
then decide whether to demote the sliced lask one level or to 
p'ace the sliced task Dehmd all ether tasks ready to run on iis 
curren: level. In either event, the system scftware will 
establish a new tirne sdce allowance for the task. This 
allowance will be in effect wnen the task ne^t runs. 

If a task voluntarily waits [a synchronous I/O order, for 
example) while it still has time remaining cr its current time 
5li:e, the reason for rhe wait is evaluated ty systerr scftware- 
]f tne wait iS for a ' long" interval , thereby making CPU time 
available to competing tasks, the task will be promoted to (or 
stay assignee to) ^ts native level when it next runs. If the 
wait is fc^ a "short" interval, thereby lim-ting the CPU time 
available tc other tasks, the task will be given priority for 
completing Its remaining slice when it next runs, but wiU then 
become a candidate for possible demotion. 

The result is that all tasks are facilitated in using a given 
time slice, but those that volunta-^ily wait for "long' intervals 
become candidates for nromotion, and those that wait for "short" 
intervals (or do not voluntarily wait at all) become canddates 

for demotion. 
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TRAP HANDLING 

The hardware provides a means by which certain events that occur 
durinc the execution of a task can be 'trapped", with control 
DEing passed to software routines designed specifically to cove'" 
the condition causing tne trap- Events such as the execution of 
a systSfTi monitor CcU . or the detection of a prograrr error, 
hirdware erro^. arithmetic overflow, or unlnstailed optional 
instruction cause traps (control transfers to designated 
software routines) to occur* 

'rap Classes Traps a"e dividea into two classes: {:) standard system traps, 
for wnich rDJtines are sjppl lea with the system, and [2) 
user-specific traps, for which users supply the^r own routines 
(handlers] - 

User Traps An aoolication progran can designate which user-specific traps 
a^e to be handled cy using the enaBl£/di =a:}le user trap 
macrocaMa {refer to the Systenj Progranmer'B Guide - yoJume II 
for details). If an enabled trap occurs in the user progra.'^, 
the Trap Manager transfers control to the connected trao handler 
for the conaition causing the trap- A trap that is enabled \s 
local to a task. Such a trap neither affects nor is affected by 
the handling of the same trap tn another task, even witnin the 
same task group. 

Any f^ap that occurs when its handler is not enabled, or that 
does not have a nandler to process it, causes the executing task 
to oe aborted. 
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SYSTEM FEATURES AFFECTING TASK EXECUTION 

While the system does mcnitor resource use within a task group 
and among task groups, tasks and task groups must cooperate in 
their use of system resources tc ensure smooth operatior^ of the 
application- 



Preorlty Level Assignments 



Priority levels 6 through 61 are availaoJe for assignment to 
system. Qevice Criver, and application tasks. The systeTn 
builder estaoHshes the priorities cf system and driver tasks 
during configuration. (On the OPS till, the Autoconf igurator 
establishes these priorities.) You assign the priorities of 
application tasks when you create task groups. Priority levels 
with low numeric va-ues have higher priority than those with 
high numeric values. The procedures for estatil ishing priorities 
are described Delow. 



Assigning Priority Levels to Devices and System Tasks 

The system builder specifies haraware interrupt priority levels 
through an araument of the DEVICE directWe in the CLM.USER 
f-}E. (The Autoconfl^urdtor is used on the DPS 6/22.) When the 
system ouilder specifies 3 particular type of device, the 
appropriate Honeywell Bull written device driver is loaded as 
pa^^t of the system. The three priority levels following the 
last one assigned to a configured device a.r^ usea by system 
tasics and cannot oe assigned to appUcation tasks. 

Reserved One example of priority Isvel assignment is shown in Table 5-1, 

Levels Levels D through 5 are assigned by the system and Art not 

available to any user. The operator tenmnal is assigned to 
level 8; however, the system ouilder can assign any appropriate 
level to the operator terminal throuoh a DEVICE di-ective. (The 
operator terminal must be at a lower (numerically higher) level 
than the Communcations Supervisor-} At initialization, the 
system bootstrap device is assigned to level 6» ThTS assignment 
refrains in effect unless changed by a DEVICE directive. 
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Peripheral PerlDheral devices may be assigned to levels on botti certrdl 
Oeuicfis processors in d multiprocessor system. Tnis assignment is done 

automaTiIca] 1> &y ttie systerr. 

Table 5-1 inoicates Inout/Dutput (J/O) devices, and not device 
drivers, to stress that eacn peripheral device inust have at 
least one level assigned to it- Except for communications 
devices, peripheral devKes cannot share a level. If there are 
two printers, each mustDe assigned a unique level even though 
there is only one copv of the associated I/O Cnver. 
Commumcations configurations require at least one nonsharea&le 
level Oedicdted to processing comnunications interrupts. This 
level must be higher than any level assigned to a communications 
device, 

Comnunications devices can share a level. For example, four 
teleprinters (TTYs) and one Visual Information Projection (Vlf) 
terfninal can be configured to share one level or to use up to 
fiw* levels. Jh^ priorities in Table 5-1 provide maximum 
throughout because devices with high transfer rates are assigned 
hicner priorities than devices with low transfer rates. 

Assignable Theoretically, the system builder could assign a level number as 
Levels high as 58 to a device. In this case, levels 59 and 60 would oe 

used by the system and only level 61 would be available for.user 
task groups^ In practice, however, the system builder would 
want ta reserve more than one level for user task groups, 
especial ly for a system with a large number of devices- If 
oriorUy levels 6 and 7 are assigned as shown in Table 5-1, the 
theoretical range of levels assignable througn CLM COMM 
directives is 8 througn 5S. For a device associated witn a COHH 
directive, the range is 9 through 58. 
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Table 5-K Banple Priority Lp\/e 
iSheet 1 of 2) 



Assignments for Tasks and Devices 



Physical 


Ba^e 






Priority 


Priority 






Level 


Level 


Use 


Comments 


D 


N/A 


Power failure handle^ 


Levels through 5 


1 


N/A 


Watchdog timer runout 


are automatical ly 


2 


N/A 


TSfl overflow 


assigned by the 


3 


N/A 


Inhibit interrupts 


system. 


4 


N/A 


Reserved 




5 


N/A 


Real-time clock 




6 


N/A 


System bootstrap 


Set to level 6 at 






device 


system Initial iza- 
tion but can be 
changed. 


1 


N/A 


Cormunications 


Must be higher 






Supervisor 


level than any 
communications 
device* 


a 


N/A 


Operator terminal 


Can be assigned 
any available 
level - 


9 


^/A 


TT^ device 


Communications 


9 


N/A 


TTV device 


devices can share 


9 


N/A 


TTY device 


priority levels. 


10 


N/A 


Removable cartridge disk 


The priority level 


10 


N/A 


Fixed cartridge disk 


for a pair of 
fixed/ removable 
disks must be the 
same. 


11 


N/A 


Diskette 




12 


■ M/A 


Diskette 




n 


r*/A 


Diskette 




14 


r^/A 


Line printer 




15 


^fh 


Card reader 
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Tafile 5-1- Sdfnple Priority' Level Assignments for Tasks and Devices 
[Sheet 2 of 2} 



Physica'; 

Priority 
Level 


55 se 
Priority 

,evel 


Use 


Ccrments 


16 
17 
IB 


N/A 

N/A 
N/A 


Reserved ty system 
Reserved Dy system 
Reserved Dy system 


The three levels 
fol lowing the last 
device-assigned 
level are usefl by 
tne systen. 


19 
2C 


D 

1 

ID 


Tasfc group A 
Task group B 

Task group n 




> 








6Z 
z2 


N/A 

N/A 


Reserved t^y systerF 
System idle loop or 
task d1 spatcher 


Always active. 
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AsstgiUng Priority Levels to Application TasltE 

Base You assign prioriti- levels to user tas^ groups and tasks when 

Priority you create or spawn them. The command to generate a task group 

Level contains an argument tfiat specifies the base priority level for 

Che task group. The base priority level Is relative to the 
highest number priority level assigned to a configured device. 

When a task grouo is assigned a base priority level of zero, the 
lead task of the group executes at the physical interrupt 
priority level tnat is three level numbers above the highest 
level number assigned tc a configured device. When other tasks 
In the same task group are created or spawned, they are given 
level numbers relative to the base priority level assigned tc 
the task group. 

Physical The physical interrupt level at which a task executes is the sum 

Level of the following: 

1. The highest level nurrtfer assigned to a configured device 
plus A. 

2- The base priority level number of the task group 

3. The relative priority level- of the task within that group. 

This sum must not ejtceed 62. 

Recommended Interactive user tasks are usually given higher priorities 
Priorities (lower level numbers) than absentee user tasks. Tasks that are 
]/C-bound should be run at a higher priority than tasks that are 
Central Processor (CP) bound. This permits I/0-bound tasks, 
which run in short bursts, to issue I/O data transfer orders as 
needed, wait for J /O completion and, while in the wait state, 
relinquish control of the central processor to CP-Dound tasks. 
Otherwise, if the CP-bound tasks have a higher priority, the 1/0 
devices would be idle while 1/0-bound tasks waited to receive 
central processor time. (Timeslicing minimizes the ability of 
CP-bouna casks to interfere with interactive and 1/0 bound 
tasks.) 



Logical Resource Numbers 



A Logical Resource number (LR^i) is an internal identifier used 
to refer to task code and devices independently of their 
phi-sical priority levels. Use of LRNs makes Assembly language 
application task code independent of priority levels so that, if 
circumstances require a change 1n priority levels, the task code 
does not have to be reassembled. 
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Device Logical Resource Numbers 



The B^sterp uses DEVICE directives to assign LRh values. Device 
LRNs mav have values 'rom 2 through 252, and from 256 through 
4002- Irn 15 usea 'or the operator terminal; LRN 1 15 used 
for tne bootstrap device; and LRfJS J003 through 4095 are 
reserved for other system uses. Figure 5-3 is an examole of 
LR^ assignments for devices and s^steir tasks- 



LRN 


Use 





Operator terminal 


1 


System dish 


Z 


fieserved 


3 


System disk companion {lf any) 


4 


User aspect of dual-purpose operator terminal 


5 


Other devices 


• 





Figure 5-3, Example of LRN Assignments for 
Si-stem Tasks and Devices 



A^fication Task Logicaf Resource Nujnbors 

LRN assignments to application program tasks within each task 
group are not dependent on the system configuration on y^hich the 
application task group 15 running. You can assign LRNs or have 
the system select the highest numbered LRN Bvailanle at task, 
creation . 

Assigning lRNs are assigned to task code within an Assemby language 

LRNs aoplication program through specif ICEtion of the Create Group 

and Create Task mac-^ocalls as v^eT as the mac-ocalls that build 
data structures (JIORB, STRB, and so forth). LRNs can be 
assigned at the control language level through the commands for 
the creation of task groups and tasks. 
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LRN Values An LRN for an apDilcation task can have any value from through 
4095. Within a task grojp, the LRN for each task must be 
iimquE. More tnan one LRN can be associated wUh the same 
priority level (for example, two tasks at level 23 can have LRNs 
of 2B and Z9, respectively']. 

Non-LRN Two kinds of tasks do not have LRNs: 
Tasks 

m Tne lead task of an> task group 

• Any spawned task. 

Logical File Numbers 

Logical file numbers (LFNs) are internal file identifiers 
associated with file pathnames at the source language program 
level or at command level- LFNs can be used to reduce program 
dependence on actual file pathnames (which are likely to vary}. 

Assigning LFNs can be associated with file pathnanes in Assembly language 

LFNs or COBOL programs, or through Create File. Get File, and 

Associate comrrends. 

LFh Values An LFN ca'r\ have any value from through 4095- 

Task and Resource Ckiordination 

Tasks can be coordinated in either of two ways: 

• Through the use of tasking requests 
m Through the use of semaphores. 



Tftsk R«qussts 



One task can request another tc execute asynchronously with it, 
or the requesting task can later wait for the ccrrpletion of the 
requested Usk. Both tasks have access to the request' block 
provided by the requesting task, and can use it to pass 
arguments between thenii 
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Semaphores 



Semaphores support an application-oeEignec agreement among tasks 
to coordinate tne use cf a resojrce such as tasK cnQe or a 
file- A semaphore is defined by a task within a task groua and 
is availanle only to the tasks within that group. Use of 
semaphores in an application is essential if the application has 
multiple tasks anc is sharing data in memory. 

For each resource to be controMed, you define a semaphore and 
giwe it a 2-charac1:er (ASCII) name. The semapnore name Ss a 
system symbol reccgmzed b> the system control software: it is 
net a program symbol that needs linker resolution. 

Resource In controlling resources, the agreement is that eacn requestor 

Coordination of a resource whose use must De coordinatec! issues appropriate 
system service nacrocails to the named semaphore to request or 
release the resource. The task that defines the semaphore 
assigns the semaphore's initial va)ue. The system control 
software maintains the current value of th^ semaphore so as to 
coordinate requesters cf the resource being contralled- A 
requester obtains use of a resource if the senaohore value is 
greater than zero at the time cf the request. If the value ls 
zero or negative, the requester is either suspended (waiting for 
the resource) or ncti-^ied that no resource is availablej 
depending on how the request was made. 



Semaphore 
Wacrocal Is 



System service macrocalls are used to: 
9 Define a semaphore and giwe an initial ^/alue (SDFSH) » 



Reserve a semaphore-control led resource (SRSVSM)- This 
macrocall suDtracts a resource or queues a waiter for the 

resource (that is, it decrements the current-value 
counter). tRSVSM suspends the requesting task until the 
resource is ready. 

Release a semaphore-controlled resource (3RLSM) . Th^s 
macrocar adds a resource or activates the first waiter on 
tne semapnore queue (that is, it increments the 

current-value counter)* 

Recuest the reservation of a semaphore-controned resource 
($fiQSM). This macrocall queues a recuest block (SRB) if the 
resource is not available (that is, it decrements the 
current-value tDunter), The 'requesting tasfc must test the 
queued SRB subsequent to the request in order to determine 
when the resource is granted. The requesting task continues 
executing until it executes a SRSV5H macrocall; then it 
waits. 

Delete a semaphore (SDLSH). 
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Example A semaphO'-e is a gating mechanism. The initial value you give 

to it depends on the type- of control you wdii to exercise. For 
e>;ample, assuFis that you want to restrict access to a particular 
resource to one user at a time- '^he mechanism would work in the 
fol lowing way: 

1- Task A defines a semaphore by issuing the macrocall; 

$DFSM ZZ 

Omission of the value argument causes the Initial value to 
be set at 1- 

2. Task B now issues a (RSVSH macrocall. The counter Is 
decremented to 0. Task S gets the resource for itself, 
knowing that no other task using the senaphore mechanism is 
noyi using or can obtain the resource- 
s' Task C Issues a $R5VSM macrocalK The counter is 
oecremented to -1, Task C is suspended and put on the 
semaphore queue in f1rst-1n/ flrst-out order (because Task B 
is still using the resource). 

4» Task B issues a SRLSM nacrccall when it finishes with the 
resource- The counter is incremented to 0< Task C now gets 
the resource- After Task C issues the SR;_SM macrocall, the 
value again becomes 1. 

Use of resources by more than one user at a time can be arranged 
by adjusting the initial value of the semaphore. For example, 
an ini-ial value of 2 allows two users, a value of A allows four 
users, and so on. The value chosen as the initial value cf the 
seniaphore depends on the nature of the resource and its intended 
use- 

If it is undesirable for a task to be suspended while a resource 
is in U5E, the SRQ5M macrocall can be used instead of $RSVSM to 
reserve a resource, $R05M is an asynchronous reservation 
request [$R5V5M is a synchronous request) that causes a request 
block to Pe queued for the resource so that the issuing task can 
do other processing before the needed --esource Is available. 
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TASK HANDLING 



her 



More than one task can be concurrently active. In i 

muUiprogramriing environ^nent , a task in each of several task 

groups can de active ano compete for system resources. Anot 

possibility *s a fnul titasking application where several tasks 

executing under one task group can oe active to compete for 
system resources among tnemselves and with ta&ks frcHn other task 
groups- 

A FORTRAN or Assembly language program can incluae requests to 
activate several tasks anc synch.ronize their execution; these 
requested tasks can execute concurrently. A COBOL, BASIC, C, 
Pascal, or Ada program executes as a single task, but can 
include commands tc activate otner tasks- 



Task Priority Levels 

For the system to sequence t^>e execution of tasks, each task 
must be assigned a priority level. In monoorocessor systems, 
task competition for the central processor resource is governed 
by tne hardware/firmware linear priority scan of level activity 
indicators. Tasks on the same priority level execute serially 
in tne orde^ in which chey are requested. In multiprocessor 
systems, tasks d.rB ordered in a software queue according to 
their priority levels. The task at the too of the queue is 
dispatched when a processor becomes free, ^hen it is assigned 
to a processor, the task executes at the same priority level as 
it would on a monoprocessor system. 

The highest priority active task receives all avaiUble central 
processor time uniil it waits, exceeds the timeslice value, 
terninates, or is suspended- In both monoorocessor and 
multiprocessor systems, the task can be interrupted by a higher 
priority task- 

Oevice It should be noted that all aevice drivers are considered to be 

Drivers tasks in the above sense. Using the File System, buffered 

device drivers can execute concurrently ^ith tasks. Drivers 
execute on :he central processor priority levels assignee to 
individual devices and thus nave their own contexts* The device 
drivers orovioed in the system are written in reentrant code, 
are capable of servicing multiple devices, and execute on any 
central processor in a multiprocessor system. 
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Task Activation 



A user task becomes active when a Spawn Task or Enter Task 
Request ccrnmand is issued ^or U, The Spawn Task cormand can 
request that the invocation of the task de deiayed until a 
specified time interval has elapsed, FORTRAN prograns can cause 
a task to become active through the START and TRNON statements- 
Assembly language programs can issue a $RCTSK OR $SPTSK 
macrocall to actiua::e a user task. Any application program can 
issue a conrmand to spawn or request a tas^ b^' calling the ZXEXCL 
run-time routTne. 

When you want more than one task to execute concurrently, you 
must specify eacn task In a Create Task or Spawn Task command 
(or system service macrocall)- 

The procedural code for a requested task Is either in a unique 
bound unit or in-a bound unit shared with a task that was 
previously created. When a task is requester the system 
searches for its identifying LRH in the table of LRNs associated 
with the task group under which the task is e>iecuting» The 
system activates the task, if it is not already active. 



Task Termination 



To terminate, tasks of Assembly language programs must contain a 
Request to Terminate (STRWRO) macrDcall- Compilers provide this 
call in the object text. STRMRO is executed after the task 
completes execution- 
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TASK STATES 

Tas<£ can exist in any of the 'ogicai states aescribed below. 

Dormant A task is in the dormant state when there ^s no current recjjest 

for it, A task enters the dorniant stats if it is createc Qjt 
never requestsd, or when a tenmnate request U issued aoainst 
it. A task remains dormant until a request is placed acainst it 
or it is deleted. If deleted, it is erased, memory is reused, 
and the task cannot be reactivated. 

Active A task is in the active staze wnen it is executing or when it ^s 

ready to execute if its priority level becomes the highest 
active level in a central processor. A task remains active 
until it waits, terminates, or is suspended. Tasks in the 
general ready Queue are active* 

Wait A task is in the wait state when it is not executing. It may 

have caused Its own execution to be interrupted until (1) the 
completion of an event such as the completion of a requested 
task, nr [2) a timer request 1s satisfied, or (3) a task 
releases a serraphore- A waiting task loses its position in the 
priority level round-robin queue. 

An 'JO O'der to disfc, magnetic tape, the operator terminal, or 
an unbuffered card reader usually results in a wait condition. 
Task code written in FORTRAN or Assembly language will a)so wait 
1n the fonowing circumstances: XI) a write order is issued to 
an interactive terminal or to a printer when a previous write 
has not completed, (2) a read order Is issued before the 
transfer of the current fiessage from an interactive terminal Is 
complete (the RETURN key is not pressed). In COBOL, these 
circumstances result in a wan if the program is executing its 
I/O statements in synchronous mode; otherwise, if In 
asynchronous mode, a status code value of 91 is returnee with no 
waiting. 

Suspend A task is in the suspend state when it is removed from execution 

by an external human action (for example, the operator ertering 
a Suspend Group corrmand or a user interrupting a program with a 
Break actlor). The task is activated through another human 
action [for example, the operator enters an Activate Group 
conmand or a user enters a command after the Ereak action). 
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INTERTASK AND INTRATASK GROUP COMMUNICATION 

Information can be passed among task groups and tasks by means 
of request blocks* coimion fi^e&, and the message facnu>. 



Request Blocks 



Task code written In Assembly language can pass information to 
other AssKTibly language tasks in the same task group by using 
variable-length request blocks. The request blocks can contain 
data or pointers to information structures. All request blocks 
must be in common address space so that they can be shared by 
the tasks. (Refer to the System Pripgrarnmer's Guide for details 
on building request blocks.) Higher level languages cannot use 
request blocks directly; they require called subroutines written 
in Assembly language. 

Common Ries 

Tasks within the same task group and tasks v*ithin different task 
groups can communicate through disk files. The concurrency 
status must be the same for all tasks using the files. The 
requesting tasks must have access rights to the files. 

Pipes A pipe is a special type of sequential file that also provides 

synchronization and queuing facilities to cooperating tasks. 
Pipes are used by tasks in different task groups (applications) 
or in the same task group, to corrmunicate with each other. 
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Message Facility 



The message facility allows two or nore task groups (users) ar 
two or mere tasks within d '.asfc group to camnunicate with one 
another, Tnis cofmunication ^= accomplTsheO through containers 
called mailboxes. Messages [requests) sent to a task or task 

grouD are cueued in a maiibo and are dequeued when received- 

Tc control the sending and receiving of messages, the /message 
facility proviaes a number of fnacrocalls and commands. One set 
of fnacrocalls (Initiate, Send, ana Terminate Message Group} 
allows a message [a request) to be sent t-c a ma'lbox; another 
set cf macrocails (Accept. Receive, and T?nninate Message Group) 
allows a message to be received from a mailDox- Cormiands are 
provided to allow you to senc, recei^^e, list, and cancel 
messages (requests). The Mail command is provided to allow you 
ts send messages (mail) to another user's mailbox and to display 
mail in ^our own mailbox, 

Deferreo processing of print and task group requests \s carried 
out through the use of the message facility. Deferred 
processing is described later in this section- 
Before the message facil-ty coimands or macrocails can be U5ed» 
and before the deferred orocess'ng of prim anc task grouc 
requests can be initiated, you (or the operator) must create the 
mailboxes and activate the message facility task. 

The paragraphs fcelow cescribe mailbox creation, the activation 
of the message facility task, and the command and macrocall 
interfaces . 
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Creatir^ Mailboxes 

Three steps are involved in the constructior of mailbcJtes. You 
must (1} create the nailbox root directory, (2) create the 
mailboxes, and [3] set access controls on the created 
mailboxes, (Refer to the Cosm^dnds manual for details.) 

The mailDox root directory Is the directory that is to contain 
the simple names of the mailboxes. 

The systefp assumes that the mailbox root directory is In the 
>MDD directory* [An HDD directory is supplied on the system 
roQfc volume.) Vou, however, are free to create your own mailbox 
root directory through the Create Directory command- 
Each mailbox is created through the Create Mailbox command- 
Ttil5 ccmfnand creates a directory corresponding to the nailbcx 
namt and a file ($MBX) within that directory defining the 
mailbox attributes. 

Setting To prevent unauthorized use of the message queues, you should 

Access set access controls as follows: 

« Senders must be given list access on the directory defining 
the mailbox. 

• Receivers must be given read access on the fWBX file for a 
given mallbojt- 

Individual mailboxes can be deleted using Delete Mailbox 
commands. 

Activating Message Facility Task 

The Start Hall operator command activates the message facility. 
This conmand contains an optional argument used to set the name 
of the mailbox root directory to other than the default 
directory pathname (>MDD). 
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Message Faeilrty Command Interface 

Tne comnands tnat can be used to send/receive messages trnail] 
arE MaM (MAIL). 5ena Message MallDox (SMM). and Accspt Wes:ags 
Mailbox (AHM] , Cormands are also proviaed to list and delete 
messages. 

Mail CDrmard The Mail cormand (a'so referred to as the local rDail facility) 
is used to send ana receive muUiline messages to/fron trie 
mailbox whose name (id) Is tne same as the person 10 of the 
receiving user, A message sent by a Mail comTiand is queued in 
tne mallDOX and dlsolayed oni^ 1f the receiving user issues a 
Hail ccmnand. 

To send a mail message, you Issue ttie Mail carmanO, specifying 
the mailbox id (person ic) of tne user to receive the message. 
The message to be 5snt can be located In a file (named Dy an 
argument of the cofnmand) or it can be entered after the Mail 
corrmand has been invoked- 



receive mail messages, you Issue the Hail comand without 
arguments. The rontents of your mailbox are displa^&o when the 
command Is executed. If you request deletion of the messages, 
they are daJetec from the mailbox after being displayed, 
Otnervise, the m^ssaoes remain in the mailbox. 



SMM and ^m 
Commands 



The Send Message Mailbox (5HM) ana Accept Message Mailbox (AMM) 
cormiands (also referred to as the local message facility; are 
used for single-line messages that must oe vewed inmediately or 
at a spEc-if'ed :ime. The AMM command is jsed to specify that 
messages sent Dy the SMM command be disp:ayed when received or 
at the time soecified in the SMM comand. 



To send a message, you issue the SMM command, specifying the 
person id (mailbox) to wnicn the message is to be sent, rou 
include the message in the command line. You can incjude the 
-TIME argument to specify a delivery time for the message. You 
can send a broadcast message by specifying =" In place of the 
FTHllbox in the SM" commend. The nwssage will be sent to all 
'ogged-on users who have issued an AMM command indicating their 
willingness to accept messages, " 



Tc rece-ve messages, you issue the AHM 
already in your inaiibox are dispiayeo- 
displayed when placed in your mailbox. 
time for display have not been reached 
Messages are deleted from your maflbox 
displayed- 



cornnand. Messages 
Subsequent messages 
Messages whose date 
are not displayed, 
as soon as they are 



are 
and 
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Senders can l-ee both the Mail and SMM cormiands, A receiving 
user who issifes a Wail comnand receives botf"- types of messages. 
If you issue an AMM cOFnmand, you receive onl^ messages sent by 
the Sm command, unless you specified ttie -IMBX * argument. 
Only when this argument Is specified will you receive both types 
of messages via the AMM corrmand- 

The -IHBX argument else allows you to specify by narne 
(person id) the sending user from whoin you will accept messages 
for ifTDedJate display. Messages sent by ether senders are 
stored in you^ mailoox- The -AHBX argument allows you to obtain 
messages 'ront mailooxes ether than Lne one associated with your 
person id. 

Message Facility Macrocalf Interface 

Vou can use the message facility on the Assembly language level 
by usinc the fnacrocall interface. To permit the sending and 
receiving of messages, the message facility provides the 
fol lowing macrocal Is: 

• Initiate Message Group ($MINIT) 

• Send (SMSEND; 

• Accept Message Grouo ($MACPT) 
« Receive (SMRECV) 

« Terrrinate Message Group ($MTMG1 

• Count Message Group (SMCMG) 
•Cancel Enclosure Level [$MCME) , 

The information associated wUri these macrocalls can be passed 
by means of request plowks, 

Send Message A task group that wishes tc send a message to a mailbox must 

issue a $K!wr" macrocall tc open the send-message session. The 
mailbox is ioentified by a name entered in the request block. 
As a result of this macrocall, the message facility returns a 
message id, unique to the task groups to identify the message to 
the other macrocalls (that is, the send). 

The test group then issues one or more $M5END macrocalls tc send 
messace data. The send-message session is closed by the $MTMG 
macrocall or, alternatively, by the $MSEVD macrocall. The 
sending task grouo can issue the S^^CME macrocall to delete the 
last record cf an incomplete Quarantine unit or the entire 
incomp'ete quarantine unit. {A quarantine unit is the smallest 
amount of transmitted data available tc a receiving task 
group,) Receipt of tfie i^essage can be deferred by the sender. 
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Receive A t3Sk grouo wishing to receive a message from a mailbox issues 

Message a SMACPT macrocall t:o open the recslve-rnesaage seBSion, "he 

mailbox is identified as described above for the SHINIT 
macrocall, and the message facility returns a message id to be 
usee by the SMRECV and SMTMG macrocdlls. 

The task grouo then issues one or more SMftECV macrocalls to 
receive message data. The recei ve-mes&age session must be 
closed with a SMTMG macrocall. 

The message may be accepted on the following selection criteria: 

• First available message 

• Sequence number 

• SiiDmitter name 

• Submitter name and sequence number. 

The receiving task group can request the message in record sizes 
other than those in which the message was sent. The receiving 
task group delimits the amount of received data Dy range or 
enclosure level , 

Effective Tt)t Tiessage facility can be used most effectively by two task 

Use groups wishing to carnriunicate if they both simu" taneousli^ send 

and receive a message. To accomplish this, each of the task 
groups shoulc issue the $MlNiT macrocall to open the senG- 
message session and the SMACPT macrocall to open the receive- 
message session. In this case^ the quarantine unit is the 
vehicle used to exchange data between the two task groups. 

DEFERRED PROCESSING FAQUTIES 

The system's deferred processing facilities are supported by the 
message facility (refer to "Message facility" above). In 
deferred processing/ the messages are requests. 

Deferring tne execution of interact-ve and absentee task group 
requests fTia<es it possible for you to gain greater control over 
the processing seouence- Deferring print requests allows you to 
obtain :>rogram independence from the availabi "ty of print 
devices. Queuing and later transcribing reports provides a 
spooling capability that places printing and punching outside of 
program contej<t. 
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Deferring Task Group Requests 



When cUcing an interactive or absentee task group request, you 
can have the reqjest entered in a disk queue and can postpone 
any action being taken on the request until a specified timet 
When the request queue structures are on disk, memory space is 
conserved and the data in the queues can be recovered tn the 
event of a system failure (refer to Section 6). 

AssuTTing that an TnteractTve and/or absentee task group has &een 
created, two steps are reauired to defer group requests. The 
operator rriL^si create the request queues (mailboxes), and you 
must issue task group requests with optional arguments 
specifying the time each request is to be activated- 



Cr«atlng Task Grotjp Request Queues 



The operator uses the Create Group Request Oueue cotmiand to 
create queue structures in which requests issuec to a given tast 
group will be stored* The operator must also Issue a Start Mall 
corrmand if one tiad rot been previously issued. 



Queuing Task Group Requests 



You queue task group requests by issuing an Enter Grouc Request 
ctMTfFiand- Vou can postpone action being taken on a request by 
specifying the -DFR (defer for interval) or -TIME (defer until 
date/time) arguments. 

Once the operator has issued a Create Group Request Oueue 
comnand for a task group, all further requests for that group 
are queued whether or not the requests are being deferred. 

If the operator does not Issue a Create Croup Request Queue 
comand, you can still submit group requests but will not be 
able to defer the requests^ 
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Deferring Print Requests 



The system proviGSS a deferred printing capability undS'" wtilch 
your recuests for Drinfng specified files are Queued in memory 
0- disk mallDOxes, The actual transcription of tne files is 
done at a later time, uncer the control of an operaior-c^eatEd 
system task group called a daemcn. 

After you submit a deferred print request, you can resuire normal 
activities, log off, or reboot ^he system without losing ttie 
reques::. 

The tnree steps involved In deferrec print orocessing are (1) 
creating the mailboj^es, (2) activating the daemon, and [3} 
queuing the print requests. The 'nformation in the following 
paragraphs Is conceptual. Detailea procedures for deferrea 
printing are given in the Systein User's Guide^ 



Creftting Print Request Mailboxes 



The operator establishes the mailboxes that are to contain the 
queued print requests. The mailboxes can be in fnemory or or 
disk. The mailbo>: names must oe in the form SPR-Qn (n is an 
integer from 1 through 9 that identifies tne relative priority 
of the queue, with 1 Deing the highest priority and 9 the 
lowest). 



Creating the Print DaAmon 



The operator is responsible for defining and activating the 
daemon to process the print requests- 

Ta create a daemon task group, the operator issues a Start Mail 
commanc (if one was not already issued), a Create Group cortmand 
naming the daemon to be created, anc an Enter Group Request 
command identifying the mailboxes to be used for queuing the 
requests and the devices to be usee for printing- 
Multiple daemon task groups can be run concurrently, using 
common or separate sets of rnailboxes and primers. 



Queuing Prvit Requests 



Once the daemon task group is active, you can queue, print, or 
punch requests oy issuing Deferred Print commanas. You can 
employ the -TIME argument to defer the printing of a file unti 
a specified date and time- 
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Queuing and Transcribing Reports 



Any file ^n print or punch format (i*e., any report file) can be 
queued and subsequently transcribed to an available printer or 
card punch. Report queuing and transcription is a spooling 
capaDility that provides automatic and raanual report 
transcription, time-of-day printing or punching, and an 
automatic setup function that includes a sample transcription 
file (template). 

The report queuing and transcription facilities control report 
transcription outside the context of the program- Reporting 
procedures for identical software can be totally different in 
different situations without requiring reprografming. 

Report queuing and transcription Uave three major aspects: 
creating a report queue, queuing a transcription request, and 
transcribing a report. 

Creating Report QuwLies 

A report queue is a directory that alloi^vs you to place a report 
transcription request in a queue and subsequently transcribe the 
report. Report queues ar& created, modified, and deleted 
through Report Queue Maintenance (ROM) commands- The 
characteristics of the report queues are determined when the 
queue Is created; the contents are determined wher a report 
transcription request is placed in the queue, 

Reoort Qjeue When the report queue is created, a report queue profile file iS' 
Profile built- The report queue profile file designates the 

characteristics of reports whose transcription requests will be 
entered in the report queue- The report characteristics 
include; 

« Name of form descriptor 

• Format of reports to be queued (print or punch) 

• Transcription mode {automatic or manual) 

e Column number at nfhich printing is to begin 

• Line at which printing is to begin (head cf form) 

• Nunfcer of print lines per inch 

• Number of ccpies of report 

• lime at which report is to be transcribed 

• Heading 1 ine 

• Destination line. 

The report queue profile file is complete when the report queue 
is created; however, various aspects of the profile can be 
overridden when the report transcription request is queued. 
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Queuing Report Requests 



The name of a report t& be suosequently pointed or pLrched is 
placed In a report queue tnrougri the Queue ReDort (ORP*^) 
cormiand. This command alsc associates with the report a 
soecialized report Queue profile f^)e that governs the ce^alls 
of the report transcription* O-^ce a request nas beer queued, it 
remains queued until tne file has beer transcribed or the 
request pathname has been deleted through a report queue 
maintenance renew or delete function. 

Transcribing Reports 

Previous''^ queued reports are wrUten to a printer or card punch 
through the Unspool JUWSP) command- A single UNSP conrmand can 
unspool all current and future requests. The printing or 
punching characteris:.1c5 are'determined by the reoort queue 
profile f-ie created "hrcugh the 9.QH ccrrmand, t,^e specialized 
report queue profile -^He created by the ORPT command, the 
ij&er s activities, and the arguments specified m the UNSP 
corrmand. 

The UNSP ccJimand defines the report queue and the hard copy 
device to be used. After the corrniano is e>!ecutec, the 
specialized report f^le (if any) is deleted from tne report 
queue- All reports whose profile matches tne specified p-ofile 
are unspooled in a single 'nvccation of UhSP, 

The report queue profile file can ^oecify tia" the reoort ^s to 
be transcribed automatically or manually. 

Automatic Automat-c transcript'on is used when constant monitoring of a 

Mode ^eport ousje -s aesirec- When there is nc transcription 

activity/ in progress, tne unspool routine suspends itself for 
1-fmnute intervals. When transcription of the queue is 
activated, each report in the queue ^s printed immediately 
unless one o"^ the following is true: 

• Manual mode was specified in the controlling profile- 

• Tne specified time cf day for report transcription has not 
been ■'eached [or exceeded)* 

Manual Mode Manual mode is used to transcribe reports in a nonautcmated 
fashion. When i'Ou require the reports, you issue the UNSP 
cormiand* A'^ reports en the Queue are transcribed immediately. 
regardless of time or nicGe, When the queue is empty, UNSP 
terminates- 
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